Ham Radio 2000 #2

home *** CD-ROM | disk | FTP | other *** search

/ Ham Radio 2000 #2 / Ham Radio 2000 - Volume 2.iso / HAMV2 / MISC / G1SMD / G1SMD.TXT < prev next >

Wrap

Text File | 1997-11-29 | 35.6 KB | 619 lines

=============================================================================== Filename: G1SMD.TXT Date: 1997-Nov-15. ------------------------------------------------------------------------------- Version: 01 Author: Ian Galpin, G1SMD. email:<g1smd@amsat.org> ------------------------------------------------------------------------------- The Year 2000 is coming and many Amateur Radio operators and computer users are still very much in the dark as to how it will affect them and the software that they use. This short guide and list of recommendations hopes to put that right. =============================================================================== This file may be distributed via Magnetic Media, via Internet, or via Packet Radio, as long as the file is distributed in whole without any modification. ------------------------------------------------------------------------------- This file may be incorporated in a '.ZIP' file with other files as part of a software release of Amateur Radio (or related) program or programs. It may be incorporated within the documentation file of such programs as long as the wording remains intact and unmodified, and this notice is included in whole. It may be included as part of the 'Install Diskette' of a software package. ------------------------------------------------------------------------------- If you incorporate this file in your product, you are encouraged to send a note of your Callsign/Name, Company, Program Title and brief details, and your email and Web address, to G1SMD <g1smd@amsat.org> so that the latest version of this file can be sent when available, and so that your product can be listed on and linked from G1SMD's and other Amateur Radio Web Pages. There is no fee. ------------------------------------------------------------------------------- Please notify G1SMD of any errors, or omissions, or to suggest any changes. ------------------------------------------------------------------------------- Title: Amateur Radio, The Year 2000, ISO 8601, and Computer Software. =============================================================================== The Year 2000 is coming and many Amateur Radio operators and computer users are still very much in the dark as to how it will affect them and the software that they use. This short guide and list of recommendations hopes to put that right. The inclusion of this file within a program package means that the author of the software is aware of the following points, but this is no guarantee that any of the software actually conforms to all of the guidelines listed here. Carefully check the program documentation for the software author's comments on this. Questions about a particular piece of software should be directed to the respective software's author and NOT to G1SMD. Thank You! ------------------------------------------------------------------------------- There are several problems with the Year 2000: 1. Computer hardware may not give the correct answer when it tells programs the current date and time (but this can usually be corrected by the user). 2. Some computer software may not understand that year '00' is the year 2000 and may perform calculations as if the year '00' is 1900, or may crash. 3. Dates may become ambiguous to the users of some programs (The adoption of the ISO 8601 date and time standard can eliminate this problem). ------------------------------------------------------------------------------- What can be done about all of this? 1. Computer hardware may not give the correct answer when it tells programs the current date and time (but this can usually be corrected by the user). There are many problems here. It must be understood that an IBM-compatible PC has several sources of Date and Time information. At the heart of the PC is a chip called the Real Time Clock (RTC). This clock chip is crystal controlled. It is also kept running by a small battery whilst the computer is 'off'. The RTC is sometimes known as the 'CMOS clock'. Being crystal controlled, the RTC is usually a very stable time source. The RTC usually only starts slowing down when the battery is nearly run down. Batteries may be NiCad or Lithium. They may clip in or be soldered on, and must be replaced with the correct type. If the battery appears to be leaking chemicals then it must be replaced. If it is a Lithium type cell it must be replaced. If it is a Ni-Cad (and it is not leaking - many do after about 4 or 5 years) then it can usually be recharged by leaving the machine on for a few hours, the charging circuit is already built in to the computer hardware). The RTC in most machines has a fault such that when 1999 ends the date and time advances, but the century information is not updated. This means that the date after 1999-Dec-31 becomes 1900-Jan-01 instead of the intended 2000-Jan-01. Programs that use the RTC will therefore instantly go wrong at the beginning of the Year 2000 as they think the year is now 1900 if the machine is on and running at the time when this happens. The following day the RTC will say the date is 1900-Jan-02, then 1900-Jan-03 and so on. The other source of Date and Time information in a PC is the DOS clock. This clock is really a 'software clock' which is interrupt driven within the DOS operating system. The DOS clock only runs while the machine is on, and is lost as soon as the machine is switched off. If the machine is on and running at the end of 1999, it will be seen that the DOS clock does correctly advance to the year 2000. Programs that are using the DOS clock (and use a full 4-digit year) will usually carry on working correctly for a while (but read on, there is a catch ...). The problem for many users will come when they re-boot the machine. The same problem will occur for users that had the machine off when 1999 ended and are switching it on for the first time in the Year 2000. Note: It doesn't matter if this is on January 1st, or days, weeks, or months later, the same thing will happen to all users at that time, as follows. When the machine is switched on, or just rebooted while already on, one of the first things that happens is that DOS reads the Real Time Clock to find out the date and time. DOS uses this information to initialise the DOS clock. The problem is that if the RTC shows a date outside the range 1980-Jan-01 to 2099-Dec-99, then DOS will default to a hard-coded error condition where the DOS clock is set to 1980-Jan-04. This is what will happen in the Year 2000, when everyone's RTC is running with the year as 1900 due to the fault described above. Note: When DOS defaults to 1980-Jan-04 this does NOT change the Date in the Real Time Clock, only the DOS clock is set to this value. Since the Real Time Clock will still continue to advance through the 1900 dates one day at a time this means that DOS will default to 1980-Jan-04 each and every time the machine is rebooted or switched off and on. This will in theory continue to occur every day for the next 80 years until the RTC actually reaches the date 1980-Jan-01 (which is a valid date as far as DOS is concerned). So the user must intervene and set the RTC date correct in order for the computer to run with the correct 2000 date in future. There is another error condition built into the date/time routines in DOS that can be mentioned here. If an invalid BCD (Binary Coded Decimal) number is found in the RTC (a month number of '3A' for example) then the DOS clock will default to the '1980-Jan-03' date instead. This is sometimes found on machines that develop a fault, or have been exposed to a static-electricity charge that has corrupted the contents of the clock chip. It is possible to set the clock to a non-valid value by using the special RTC routines built into the 2000.EXE (YMARK2000) program available from NSTL in the USA. To set the RTC date to the correct date at the beginning of 2000 you can use the DOS 'DATE' command at the DOS prompt. Be aware though that when you type 'DATE' the date shown on screen is only that from the DOS clock not that in the RTC. You need to type the new date in again even if the one shown appears to be correct (as would happen if the machine is running at the end of 1999 and the DOS clock advances to 2000 whilst the RTC goes back to 1900). If you just press 'Enter' this will not update the RTC date, and the DOS date will again go wrong at the next reboot, because DOS reads the RTC every time the machine is switched on, and every time the machine is rebooted whilst already on (when the RESET switch is pressed, or when the 'Control-Alt-Delete' key sequence is used). When using the DOS 'DATE' command to set the date, make sure that you use DOS Version 3.3 or later. Machines that were around when earlier versions of DOS were current did not include an RTC chip (DOS asked the user with on-screen prompts for the correct date and time every time the machine was rebooted) so DOS versions before 3.3 do not have a function to write to the RTC. The first 286 machines with an RTC circuit built in often came supplied with a separate SETCLOCK (or similar) utility program just in case the version of DOS used with the machine could not write to that clock. The sympton here was that having set the date and time using the DOS functions, when the machine was rebooted then the date and/or time went back to the 'old' value (because using the DOS command only the DOS clock had been set, not the RTC!). Modern versions of DOS write to both the RTC and DOS clock when a new date and/or time is typed in, so overcoming this problem, but pressing 'Enter' only, usually does NOT update anything. In the present we must note that although the majority of machines will try to go back to 1900 (RTC chip) and/or 1980 (DOS clock) after the end of 1999, it is easy for users to put things right. It is important to understand that although the date may appear to be OK if the machine is left on, that the underlying RTC date is probably wrong and must be corrected (otherwise programs that use it will instantly go wrong, or all programs will fail when the machine is next rebooted and DOS picks up the wrong date). The RTC chip contents can be viewed with a special utility such as VIEWCMOS.EXE by GTBecker of RighTime (USA) to confirm all of the details described here. It is worth noting that some very new machines claim to be '2000-compatible'. It is true that when the machine is rebooted that the BIOS catches the '1900' date read from the RTC and changes it to '2000', but this correction can only occur at boot up. Even for '2000-compatible' machines the RTC date will still usually go back to 1900 if the machine is actually on and running at the end of 1999. This requires that the machine be rebooted, or the user manually correct the date, to ensure correct operation in the future, or to avoid programs that use the RTC crashing as soon as the year 1999 ends. Beware of a few older rogue computer boards that do not allow any date after 1999 to be typed into the system clock. The only option here is to replace the on-board BIOS chip (if available!) or to buy a complete new motherboard. For most people all that is required is to simply reset the date and time in the RTC and in DOS at the beginning of the year 2000. A special utility called Year2000.EXE from RighTime can be installed as a TSR (from a one-line command in the AUTOEXEC.BAT file) and this claims to catch all occurances of the RTC changing from 1999 to 1900 and automatically corrects it to 2000. It also checks the RTC at boot up and corrects the date if it has gone back to the beginning of 1900. Remember a machine switched off at the end of 1999, and left for several months will have a '1900-Mar' date (instead of a '2000-Mar' date!) in the RTC by then, and will still need to be corrected. Other programs, such as 2000.EXE (YMARK2000) from NSTL and DOSCHK.EXE from Saphena can perform a test of the RTC and inform you of problems with the operation of this important part of the computer system. These programs can be found on Internet (see below). There are several other similar programs available from other sources. These programs tell you what problems have been found, but do not correct those problems. There is very little that software writers can do to help users with this part of the Year 2000 Problem. Users need to understand what goes wrong, how, and why. They then need to manually correct the date (and/or time) at the beginning of the Year 2000 using the correct process; or install a utility such as the Year2000.EXE program from RighTime that will monitor the RTC for the problem and provide an automatic correction as needed. Users need to be aware of this part of the Year 2000 problem. I have seen a number of people accusing software of not being compliant, when the real problem was the actual computer hardware that was at fault. You must have the correct date in both the RTC and the DOS clock before you can actually test any software for compatibility. If the hardware is giving the wrong date, of course the software will fail! When testing software for Year 2000 compatibility, always back up all of the program and data files before carrying out the test. Always work with a copy of the data, not the original. Programs that fail the test may scramble some of their data files. Or even simpler, time limited software may exceed its licence date and expire. When the date is put back to the correct 1997/1998 date after the test, some software may still cease to function. You have been warned! There are a number of text books and magazine articles that go into more depth about the Year 2000 Problem. See those for further information. Also see the IBM publication (Ref: GC28-1251-xx) 'The Year 2000 Guide'. ------------------------------------------------------------------------------- 2. Some computer software may not understand that year '00' is the year 2000 and may perform calculations as if the year '00' is 1900, or may crash. This is the basis of the 'Year 2000 Problem' currently attracting some attention in the media. It is only half of the Year 2000 Problem, the software half. The hardware part was described, at length, above. This problem usually occurs when a program only uses two digits to represent the Year. This shorthand notation had a value back in the 1960s when computer memory was expensive, but nowadays all software should be written such that the year is shown using all 4 digits, on screen, on printouts and stored on disk in an unambiguous way. Programs that use only a 2-digit year can only span 100 years worth of dates. Mostly this means that only the years 1900 to 1999 can be used, denoting these as '00' to '99'. When the Year 2000 arrives, then Year '00' data may be incorrectly sorted to be before Year '99' data. In addition, other date based processes may fail. The difference between dates may yield incorrect answers: '2005' minus '1995' is '10 Years', but '05' minus '95' is 'MINUS 90 Years'. Some software has been modified to cover 1950 to 2049. Whilst this means that the software is 'Year 2000 Compatible' it also hides the fact that it has a 'Year 2050 Problem'. It is also noteworthy that the modified software will not accept a date before 1950. This may be important in some applications. Amateur Radio started in 1898, so it is reasonable that a log book program should cover all dates from that time onwards just in case someone wishes to preserve old logs by putting them onto computer records. The use of 2-digit years will flummox historians. In a few years time it will be unclear if the date '05/05/05' refers to '1905' or '2005' and this could be important. The usage of 4-digit years is therefore recommended, and may become mandatory in the Year 2000 on the QSL cards valid within some award programmes. Try the menu options of the software to see if a 4-digit year can be selected, then select it. If you are a software writer, now is the time to upgrade the product so that all dates use a 4-digit year. Remove code that only allows a 2-digit year, and remove the option from the menu. Users will thank you for being forward thinking when they watch competing products fail when '01/01/00' arrives on their screen. Some programs may just produce wrong answers when dealing with the Year 2000, others may suffer degraded performance. It is possible for some programs to completely crash. Consider a database program that uses a formula to find the correct record in a file. Consider that this method is supposed to evenly spread entries all through the file, rather than just sequentially writing them one at a time from the start of the file. When an entry needs to be found, a formula is run and the number produced gives the place in the file to start searching (as more than one record may give the same starting number, the record may actually be several entries further on in the file. This is still a very quick method compared with searching the whole file for the record). Now consider that the formula goes something like 'record position' equals 'order number' times 'customer reference' times 'year'. This will mean that all entries for Year '00' give a result of 'zero'. Zero is the first record of the file. So every time a record is written it will go in the first free space near the beginning of the file. As the year progresses this will mean that the program has to search sequentially further and further into the file to find a free record to write new data, rather than going straight to an area where the next free record may be only a few entries along from the starting point. Consider also that when a record needs to be read, that the program will also end up sequentially searching the file from the very beginning. This is no longer using the method that it is supposed to be using, and performance of that program will get worse as the year progresses and more records are added. Within a few months the performance may be so degraded that the program becomes unusable. Now consider that the formula could be 'customer number' times 'order number' divided by 'year'. In this case, when the year is '00', the result will be the illegal operation 'Divide By Zero' and the program may 'crash' outright. This scenario is likely to be very rare, but points to some of the problems that may be encountered 'behind the scenes' in programs that will mean that in some cases the year '00' does not compute! If you write software, do the world a favour and ensure that you use a 4-digit year all through the program (in data, on screen, on printouts, etc) and that the program can handle all years from at least '1001' to '9999'. Memory and storage space is now so cheap that taking a 2-digit short-cut to save a small amount of memory is no longer worthwhile. A reminder again, to work with copies of programs and data when doing Year 2000 testing. Expect the worst, that you'll crash the program, and scramble all the data files. See the user documentation to see if the software author makes any specific comments about the Year 2000 compatibility of the product. ------------------------------------------------------------------------------- 3. Dates may become ambiguous to the users of some programs. A date like '01/12/97' is already ambiguous. In America that date means 'January 12th', but in Britain and in some parts of Europe it actually means '1st December'. In a few years time, dates like '03/02/01' will look very strange, and may often be misread. There are several problems with that date. Not only is it unclear which digits represent the day and which the month, but it is also unclear which century the year is in. Writing '03/02/2001' solves the 'century' problem, but not the other long-standing ambiguity. There is an international standard, called ISO 8601, that can help here. But, first, consider that we all write times in the order 'hh:mm:ss'. No one uses 'ss:mm:hh' or 'mm:ss:hh'. In amateur radio we use the UTC time zone rather than Local Time. We also use the '24-hour' clock rather than the old 12-hour am/pm system. This means that we are already following the ISO 8601 definitions for times. All we need to do now is to bring our dates into compliance. To do this we simply write dates with a 4-digit year, and with the 'Year-Month-Day' order. Hyphen separators should be used between elements. A leading zero is required on the digits '01' to '09' inclusive. This is the basis for the 'Full Format for Gregorian Calendar Date' as defined in the ISO Standard. There is a variant to the ISO 8601 standard that is sometimes used. Retain the required Year-Month-Day ordering. Write the month using the 3-letter abbreviation, or write the month out in full. That is '1997-10-11', '1997-Oct-11' and '1997-October-11' are all interchangeable. I realise that '10 May 97' may seem to be clear. Whilst that is how it would be written in Britain, Americans would use 'May 10, 97'. This carries the risk that people then revert to the '05/10/97' or 10/05/97' format when writing the date in figures. If the Year-Month-Day ordering is to be used, then it makes sense to do this whether the Month is written in figures, written as a 3-letter abbreviation, or written out in full. There is already a proposal circulating that suggests adopting the ISO 8601 date and time standard (and the '1997-May-10' variant) for all facets of the Amateur Radio hobby. It will find use for computer programs and data, band reports, log books, QSL cards, email, packet radio, Web pages, magazine articles, membership cards, events diaries, newsletters, invoices and receipts - any place that dates and times are used whether computer or paper based. Astronomers have already been using the Year-Month-Day ordering for at least 200 years and it has brought great benefits of clarity, consistency, and unambiguity to published tables of astronomical data, and more recently to computer programs. Amateur radio is also an International activity and could benefit greatly by adopting this method of working. The ISO 8601 date standard ensures that dates cannot be confused with either of the old American or British ways of writing the date. The date written in the Year-Month-Day style also retains the same left to right precedence that we are already used to when writing times. This makes looking down a long list of dates and times - perhaps in a log book, or on a list of satellite passes - very much easier. The standard requires that when Dates and Times are combined that the Date is written before the Time. This ensures that there is full left-to-right precedence across all of the data elements present: from Year on the left, right down to Minutes and Seconds on the right. The ISO 8601 standard has already been adopted all around the world. In Europe it is known as 'Euro Norm' EN 28601. In Britain also see British Standard BS EN 28601. In Germany see DIN EN 28601 and DIN 5008. In America refer to the ANSI X3.30 standard. IBM also recommend it as the 'best, most complete, and permanent' solution to all date problems in their Year 2000 literature. The Year-Month-Day way of writing dates is already the default national standard in a number of countries: notably in Scandinavia (Denmark, Sweden, Finland), Germany (since 1996 - they no longer officially use 31.12.99 or 31.XII.99), parts of Eastern Europe (Hungary, Czech Republic, etc), and in most of Asia (Korea, China, Japan, and so on). The amateur radio proposal is to encourage the use of the Year-Month-Day format within software, preferably as the default and only format. Dispense with the date format menu options and all the underlying code - code that just prints the date in a different order depending on the menu selection made, only one piece of which code can ever be active at a time. This will lead to smaller programs which may run faster. If you write software, now is the time to make the ISO format the default format within your program. If you use software try the menu options to see if you can select this format. Contest entries in Europe already demand the Year-Month-Day format be used, and there are moves to standardise some parts of amateur radio software. See the ADIF standard by WN4AZY and WF1B in America and the REG1TEST format proposed by OZ1FTU and OZ1FDJ in Denmark, as well as the ISO 8601 proposal by G1SMD. The ADIF and REG1TEST documents deal with formats for storing data in amateur radio programs. In the section that deals with dates the YYYYMMDD or YYYY-MM-DD format is specified. The proposal by G1SMD also uses the same two formats. It also allows the YYYY-MMM-DD format, and extends the scope from purely data file usage to also being used on computer screens and printouts, in magazines, email and packet radio messages, and so on. QSL cards have always caused problems. A QSL card for a contact on '4/8/92' may actually be found on the '8/4/92' page of the log book, when the contact took place across the two sides of the Atlantic. A number of software writers have already agreed to make the '1997-08-09' or '1997-Aug-09' date format the default format in future releases of their software. This will help to relieve these problems with ambiguous dates. The long term aim is to make it the only format, so that dates will have the same clarity and meaning all around the world. We all understand the time '22:30:55', there should be no problems with a date like '1998-04-20'. Several US software developers are changing to the ISO method in their next release. They had always realised that the '10/20/97' format was not used outside of America and had struggled for a compromise. Now that they know that an International Standard exists, one that America has already signed up to use, this has meant that the problem has been easily resolved. When Dates and Times are stored on disk or passed across computer networks it is permitted to strip off the separators and just store/send the numbers. The Date '1997-Oct-11' or '1997-10-11' can be stored as '19971011'. The Time '20:44:59' can be stored as '204459'. This can save a considerable amount of storage space, without hindering readability. This shortened format is known as the 'Basic Format' in the ISO standard, whereas the '1997-10-11' format is known as the 'Extended Format'. Usage of this format can make the programming of software routines that deal with dates, especially those that sort data into order, trivial to write, and easier to test and verify. It is already possible to use the ISO date formats on some Amateur Radio computer software. Check the user documentation of the program to see what is available. For users who wish to set DOS up to work this way, try selecting 'COUNTRY=086' in the CONFIG.SYS file under DOS 5.0 or later (but note that the 'DIR' command will still only use a 2-digit year). For Windows, look at the options available in the 'Control Panel'. In Windows 3.x look at the 'International' Settings. In 'Date', click on 'Change'. In the 'Short Format Date' box, select 'YMD', Hyphen Separator, 'Show Century', 'Month Leading Zero' and 'Day Leading Zero'. In 'Long Format Date' select 'YMD' and using the pull down options select a 4-digit year, 3-letter month, leading zero on the day number, then click on OK. In the 'Time Format' option ensure that '24-hour' clock is selected, and that a leading zero is shown for digits '00' to '09', then click on OK. Under Windows 95 look at the 'Regional Settings' option. Select the 'Date' tab first. In 'Short Format Date' select 'yyyy-MM-dd' (this will give '1997-10-11' as the format in programs). In 'Long Format Date' select 'yyyy-MMM-dd (for '1997-Oct-11') or 'yyyy-MMMM-dd' (for '1997-October-11'). Next, Select the 'Time' tab, and change the format to 'HH:mm:ss'. At all stages, several options are available in the drop down boxes on screen. If the option that you want isn't listed, just go to the main box where the definition is shown and type the new definition in, in place of the one shown. Finally click on 'Apply' to actually select these settings. There are loads of resources out there about the ISO 8601 format as well as the wider Year 2000 Problem, with which it is inexorably linked. IBM already recommend the ISO format as the 'best, most complete and permanent' solution to the 'Year 2000 Problem' in their literature. IBM use the '1997-Oct-11' format all the way through their 'Year 2000 Guide' which can be also downloaded from Internet. ------------------------------------------------------------------------------- While we are on the subject of dates and times, it is worth noting that most amateur radio programs need to work using the UTC time zone even though the computer clock may be running on Standard Time or Local Time. (Note: 'Standard Time' here, refers to the normal Standard Time for that place on the planet, but the user does NOT adjust the clock for the effect of Summer Time, their clock being an hour behind Local Time in Summer). 'Local Time' refers to a user that adjusts the clock for the effect of Summer Time, and so moves the clock fowards and backwards an hour on occasions). You need to consider the needs of amateurs all around the world, or who may travel from place to place. There are several possibilities that need to be catered for: 1. the computer clock is run on UTC all year round. 2. the computer clock is run on Standard Time all year round (that is the standard time zone for that location, but with the Summer Time Offset ignored, in other words run on the Winter setting all year round). 3. the computer clock is run on Local Time; that is, it is changed backwards and forwards an hour between Summer and Winter. 4. The user changes between methods 1, 2 and 3 on a random basis. It is fairly simple to set up a routine that asks: 1. How many hours ahead or behind UTC the user's Standard Time Zone is. Note here, that you need to cater for times ahead and behind UTC with up to 14 hours difference to UTC and offsets in 15 minute steps. Remember, not all time zones are an exact whole number of hours different to UTC. 2. Whether Summer Time (Daylight Saving) is in force or not at present. Provide a simple method to move ahead/backwards one hour rather than changing the numbers of the offset. 3. Whether the Computer Clock is set to UTC, Standard Zone, or Local Time. This last part provides the actual translation from computer time to UTC. This then easily caters for all users. I personally leave the computer clock on UTC all year round, and run all software in UTC. But, some people who also use their computer for non-amateur purposes may not be able to run the computer clock in UTC. Programs need to be able to cater for this, to arrive at 'program time' being in UTC whatever the 'computer time' is actually set to. In many countries it is a legal requirement that log book entries be in UTC (not Local Time!). QSL cards are always exchanged with UTC dates and times on them. The use of UTC ensures that everyone talks the same language. A lot of astronomy programs usually show the current UTC Date and Time in one box, and below it the current Local Date and Time in another, with a separate position showing the relationship between UTC, Local Time and Computer Time. Be aware of the date correction that may need to be applied. An event that occurs at a Local Time of 22:00 on Monday at a place 4 hours behind UTC, will be taking place at 02:00 on the Tuesday morning as far as UTC is concerned. The general method of indicating Time Zone is also defined in ISO 8601. Greenwich, England defines the Origin. Places to the East, where time is ahead of UTC are denoted as Positive. Places that are to the West of Greenwich, where the time is behind UTC, are denoted as Negative. The difference is shown by a 4-digit number. The first two digits show the number of hours, the last two digits the number of minutes. For example, 'Eastern Standard Time' which is 5 hours behind UTC is shown as '-0500'. Indian Standard Time is 4 and a half hours ahead of UTC and is therefore shown as '+0430', and so on. This also fits in with the general methods already being used for showing latitude and longitude where signed figures are used. For latitude, North is treated as being 'positive', and South as 'negative'. For longitude, East is treated as being 'positive', and West as 'negative'. ------------------------------------------------------------------------------- The following resources may also be of interest: Magazines: ---------- - Communications of the ACM (US) 1997-May Page 26 to 30 and 111 to 117. - The Software Practitioner (US) 1997-May/Jun Page 1 to 5. - Byte (USA & Europe) 1997-Jul Page 89 to 96: Double Zero. - DUBUS magazine (Germany) 1997-Q1 Page 83 to 85: Proposal Doc. - QST (ARRL, USA) 1997-Aug Page 69 to 70: Software Traps. - CQ-TV [Issue 180] (BATC, UK) 1997-Nov Page 9 to 11. - New Scientist (UK) 1997-Nov-08 Page 59: Last Word on Y2K. - Oscar News [No 128] (AMSAT-UK) 1997-Dec Page 1. Longer Items: ------------- - IBM Publication GC28-1251-xx: 'The Year 2000 Guide' ('xx' = edition number). - International Standard: ISO 8601. - European Norm: EN 28601. - Harmonised version of EN 28601 implemented in every European country. - British Standard: BS EN 28601 (replaces BS 7151). - German Standard: DIN EN 28601 and DIN 5008. - American Standard: ANSI X3.30. Internet <http>: ---------------- <http://ourworld.compuserve.com/homepages/dstrange/y2k.htm> <http://www.aegis1.demon.co.uk/y2k.htm> <http://www.saqqara.demon.co.uk/datefmt.htm> <http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html> <http://www.s390.ibm.com/stories/tran2000.html> <http://www.kirsta.demon.co.uk/iso_8601.htm> <http://www.rightime.com/index.html> <http://www.nstl.com/html/ymark_2000.html> <http://ourworld.compuserve.com/homepages/saphena/year2000.htm> Internet <ftp>: --------------- <ftp://ftp.funet.fi/pub/ham/misc/year2000.zip> <ftp://ftp.funet.fi/pub/ham/misc/g1smd.zip> (This list will be updated from time to time in later releases of this file). The Proposal to use ISO 8601 within Amateur Radio is also supported by: G3RZV, G6CGQ, GM4ANB, DL4EBY, DL8LAQ, G3XWH, G3RUH, G4NJH, G8IQU, HB9MAO, AA7BQ, N3EQF, KP2BL, WN4AZY, W1UD, W3IS, G8EXV, G0RUR, GM3JZK, G4IFB, N0ED (G3SQX), G3SEK and many others. =============================================================================== The latest version of this document is available from: - Internet: <http://ourworld.compuserve.com/homepages/dstrange/g1smd.txt>. - Internet: <http://www.aegis1.demon.co.uk/g1smd.txt>. - Internet: <ftp://ftp.funet.fi/pub/ham/misc/g1smd.zip>. - By AX.25 request to 'CLIVE' server with message 'Download G1SMD.TXT' or ZIP. - By Internet request to <info@arrl.org> email message 'send g1smd.txt' 'quit'. - Search Internet for ftp sites and files at <http://ftpsearch.ntnu.no/>. =============================================================================== Questions and comments on this document only to: Ian Galpin, G1SMD: QTHR in any callbook 1984 onwards. Or, look at <http://www.qrz.com/> for up-to-date QTH and email listings. Email: <mailto:g1smd@amsat.org> Web Page: <http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>. =============================================================================== Document Revision History: Version: 00 Date: 1997-Oct-28 Limited Circulation Draft. Version: 01 Date: 1997-Nov-15 Added More References. =============================================================================== .end